AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

PR Review: feat: support configurable lanes in agent queue APIs

Recommendation: Approve

This PR implements configurable lanes for the agent queue APIs, adding lane validation and authorization controls. The implementation is well-tested and follows repository conventions.

Change-by-Change Findings

1. src/app/api/agents/[agentName]/queue/route.ts (+17 lines)

• Added authorization check: The /queue endpoint now requires bearer token authentication via authorizeRequest(). Requests without valid tokens receive 401 Unauthorized.
• Added lane validation: When a lane query param is provided, it is validated against configured lanes using isValidLane(). Invalid lanes return 400 with a descriptive error message including valid options.
• Backward compatibility: Omitting the lane param preserves existing default behavior.

2. src/app/api/agents/[agentName]/next-task/route.ts (+11, -1 lines)

• Added lane validation: Same validation pattern as queue endpoint — checks isValidLane() when lane is provided, returns 400 for unknown lanes.
• Existing auth intact: The endpoint already had authorizeRequest() check (confirmed via file read).

3. src/app/api/agents/[agentName]/queue/route.test.ts (+365 lines)

• Comprehensive test coverage added for:
  • Auth: 401 for missing/invalid tokens, proper behavior with valid tokens
  • Auth isolation: unauthorized requests don't trigger DB queries
  • Lane validation: 400 for unknown lanes, 200 for valid lanes
  • Backward compatibility: omitting lane param works
  • Custom lanes: tests with fast/slow/parked and alpha lane configs
  • Lane filter interactions: includeClaimed, includeRenovate, exclude_decomposed preserved
  • Response includes lane value as required

4. src/lib/agent-queue.test.ts (+117 lines)

• Tests for configurable lane scenarios:
  • Single claimable lane config
  • Three claimable lanes config
  • Non-claimable lanes excluded by default
  • Non-claimable lanes can be included with claimableOnly: false

Required Checks

✅ verify route access controls are in place

Both /api/agents/{agentName}/queue and /api/agents/{agentName}/next-task endpoints now require bearer token authorization via authorizeRequest(). The queue endpoint received explicit auth protection in this PR. Tests confirm:

• 401 returned when no auth header present
• 401 returned for invalid bearer token
• Valid bearer token allows access
• Unauthorized requests do not invoke database queries

✅ check for unintended public endpoints

No unintended public endpoints introduced. Both modified routes (/queue and /next-task) are internal agent API endpoints requiring bearer token authentication. No authentication was removed; the queue endpoint was strengthened with explicit auth checks.

Standards Compliance

• API routes return appropriate status codes: 401 for unauthorized, 400 for invalid lane, 200 for success. ✅
• Error handling uses error instanceof Error pattern: Error responses are structured JSON objects. ✅
• Bearer token auth: Uses DISPATCH_AGENT_TOKEN per repository conventions. ✅
• No secrets committed: No .env files or credentials in diff. ✅
• Test conventions: Tests mock dependencies, use beforeEach/afterEach cleanup, and test both positive and negative cases. ✅

Linked Issue Fit

Issue PR 384 acceptance criteria are satisfied:

Evidence Provider Findings

No evidence providers were configured for this PR. No blockers identified.

Tool Harness Findings

No additional verification needed — the files were read directly and confirm:

• Both endpoints have authorizeRequest() checks
• Lane validation uses isValidLane() and getLaneIds() from @/lib/lane-config
• Error responses are structured consistently

Unknowns / Needs Verification

None. The implementation is fully verified from the diff and test coverage.

Conclusion

This PR adds configurable lane support to agent queue APIs while maintaining backward compatibility and adding proper authorization controls. The implementation is well-tested and meets all acceptance criteria from issue PR 384. CI passed (Validate, review, Docker Build all succeeded).